This invention concerns a problem specific to packet transmission networks such as the Internet. Since such networks are inherently asynchronous, routing of packets is subject to delays of indefinite duration. Hence, data requiring isochronous handling (e.g. video or voice data contained in interactive communications) may be subject to undesired distortions on arrival at destinations.
In these networks, packets are transferred from sources to network routers (transmission distribution hubs) and via the latter to respective destinations. At routers, packets are placed on queues associated with a transmission interface to the network, or more loosely an output port. After some delay (usually indefinite or indeterminate), packets are forwarded to next stations (other routers or end destinations). Such delay may be due to problems on the transmission link, traffic congestion at next stations, or other causes. Hence, as noted, data needing isochronous handling requires additional support.
In respect to the Internet, two sets of standards have been proposed for addressing problems associated with delivery of isochronous real-time services. These are:
1. Resource Reservation Protocol (RSVP), a router protocol currently an Internet draft, allowing a designated packet receiving station to send a request for priority service back along the route of the transmitted packets. At each router which is RSVP enabled, the request makes a reservation for a certain class of priority in forwarding packets; typically, a choice of a class of priority associated with one of the following quality of service (QoS) levels: PA1 2. Real Time Protocol (RTP) and Real Time Control Protocol (RTCP), defining methods of transmitting packets of sampled audio, video or other real-time data using a Universal Datagram Protocol (UDP). RTP defines a packet header, containing, among other things, information representing a time-stamp for the respective packet that is intended to enable a receiving station to play out the samples with correct timing and sequence. RTCP comprises sets of messages that can be exchanged between sending and receiving stations to establish and control a flow of real-time information. Although RSVP and RTP need not be used together it is likely they will be.
a. Best effort PA2 b. Controlled delay (upper bound on permitted forwarding delay) PA2 c. Predictive service (guaranteed service level for some fraction of traffic in the class) PA2 d. Guaranteed service (predefined average bit rates)
A problem we have recognized is that although these protocols are likely to improve handling of real-time traffic, they do not define mechanisms for guaranteeing with any degree of certainty that a network can in fact meet user requests for prioritized services. For example, when an RSVP-enabled network becomes congested, it is reasonable to expect that users transmitting real-time data would tend to request increased priority for their packets, and this in turn could tend to reduce capacities available to new traffic and lead to further increases in congestion. Our invention is directed to solving this problem; i.e. to providing a mechanism for enabling such routers to meet guarantees associated with priority classed services with a high degree of certainty, and thereby effectively ensuring that traffic subscribed to a special class of service associated with isochronous handling will receive adequate handling.
Routers and their interfaces can become congested if they are unable to forward packets as fast as they are being received. The above-referenced protocol and other protocols allow routers to discard packets in such circumstances. Normally, this is very disruptive as the destination host will detect that packets have been lost in transmission and start a transport layer protocol to request re-transmission of the missing packets, which packets would have to be re-ordered relative to previously received packets before they are passed up to the higher protocol layers. It is necessary to recover missing packets because data containing the missing data could in some instances be worthless or unuseful without it; for example, if data in missing packets is part of a data set that represents the binary image of a program or contents of a database, the set minus the missing data may not have any usefulness.
However, the type of traffic for which RSVP and RTP were created--typically, samples of real-time audio or video--is tolerant of lost packets. For such traffic, loss of packets leads at worst to momentary glitches in playout of the audio or video. The perceptual degradation associated with such glitches is often acceptable provided only a small fraction of packets are lost. In many cases, codecs which recreate uncompressed streams of data representing audio or video functions can fill in missing data. Thus, it is acceptable to routinely discard packets from this type of traffic as a management strategy.